Project Genie：Google DeepMind 开启无限交互世界新纪元
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 102 次浏览 • 9 小时前
来源: Google DeepMind Blog
发布时间: 2026年1月29日
作者: Diego Rivas, Elliott Breece, Suz Chambers引言：从世界模型到无限创造
2026年1月29日，Google DeepMind 正式推出 Project Genie —— 一款基于 Genie 3 世界模型的实验性研究原型产品。这一里程碑式的发布标志着 AI 驱动的交互式世界生成技术正式走向普通用户，让"创造无限世界"从科幻概念变为触手可及的现实。
Project Genie 目前面向美国地区的 Google AI Ultra 订阅用户（18岁以上）开放，它允许用户通过简单的文本提示和图像输入，创造、探索和重新混合属于自己的交互式虚拟世界。什么是世界模型？世界模型的核心概念
世界模型（World Model） 是一种能够模拟环境动态变化的 AI 系统，它可以预测环境如何演变以及用户行为如何影响环境状态。与传统的静态 3D 场景不同，世界模型能够实时生成可交互的动态体验。
Google DeepMind 在特定环境智能体领域有着深厚的积累，从早期的 AlphaGo（围棋）到 AlphaZero（国际象棋），这些系统都展现了 AI 在封闭环境中的强大能力。然而，构建真正的通用人工智能（AGI）需要能够适应现实世界多样性的系统。Genie 3 的技术突破
Genie 3 是 Google DeepMind 于 2025 年 8 月首次预览的通用世界模型，它能够生成多样化、可交互的环境。与静态 3D 快照的可探索体验不同，Genie 3 的突破性在于：
- 实时动态生成：不同于预渲染静态场景
- 物理模拟与自由交互：突破有限的预设交互
- 突破性的场景连续性：打破固定场景边界
- 多元应用场景：机器人、动画、虚构世界、历史探索
Project Genie 的三大核心能力
Project Genie 是一个基于网页的实验性原型应用，由 Genie 3、Nano Banana Pro 和 Gemini 三大 AI 模型联合驱动。它围绕以下三个核心能力构建：1. 世界草图（World Sketching）
用户可以通过文本提示结合生成或上传的图像来创造生动、不断扩展的环境。你可以：
- 🎨 创建角色：定义你的世界中的主角形象
- 🌍 构建世界：设计独特的环境场景
- 🎮 定义探索方式：从步行、骑行、飞行到驾驶，任何你能想象的方式
精准控制增强：Project Genie 集成了 Nano Banana Pro 图像生成模型，允许用户在进入世界前预览世界外观，并通过修改图像来微调世界设定。你还可以定义角色的视角（第一人称或第三人称），在进入场景前完全掌控体验方式。2. 世界探索（World Exploration）
你的世界是一个可导航的动态环境，等待你去探索。随着你的移动，Project Genie 会根据你的行为实时生成前方的路径。在穿越世界的过程中，你还可以随时调整摄像机角度，获得最佳的探索视角。
这种实时生成机制意味着：
- 每个世界都是独一无二的
- 探索过程充满惊喜和未知
- 用户可以自由决定探索的方向和方式
3. 世界重新混合（World Remixing）
Project Genie 支持基于现有提示重新混合世界，创造出全新的诠释版本。你可以：
- 🔄 在画廊中探索精选世界：获取灵感
- 🎲 使用随机生成器：发现意想不到的创意
- 🏗️ 在他人作品基础上构建：协作式创作
- 📹 下载视频：保存你的世界和探索过程
负责任的 AI 开发
Google DeepMind 强调，Project Genie 是一个实验性研究原型，作为通往通用 AI 系统的一部分，其使命是负责任地构建有益于人类的 AI。当前模型的已知限制
由于 Genie 3 仍处于早期研究阶段，存在以下需要改进的方面：
- 视觉保真度：生成的世界可能不完全真实，或无法始终严格遵循提示/图像/物理规律
- 角色控制：角色有时可控性较低，控制响应可能存在较高延迟
- 时长限制：单次生成限制在 60 秒以内
访问方式与展望当前可用性
- ✅ 目标用户: Google AI Ultra 订阅用户
- 🌍 地区: 美国（18岁以上）
- 📅 发布时间: 2026年1月29日起逐步开放
- 🔮 扩展计划: 未来将扩展到更多地区
长远愿景
Google DeepMind 表示："我们期待看到用户创造的无限多样化世界。随着时间的推移，我们的目标是让更多用户能够体验这些技术和体验。"总结
Project Genie 的发布代表了 AI 世界模型技术从实验室走向用户的重要一步。它不仅展示了 Google DeepMind 在生成式 AI 领域的领先地位，更为创作者、开发者和普通用户打开了一扇通往无限交互世界的大门。
随着技术的不断成熟，我们可以期待更长的生成时长、更高的视觉保真度、更精准的控制能力和更广泛的地区覆盖。
Project Genie 不仅是一个工具，更是通往 AI 驱动创意未来的窗口。
本文基于 Google DeepMind 官方博客文章翻译整理，原文发布于 2026年1月29日。
Wayfair 借助 OpenAI 大幅提升商品目录准确性和客服效率
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 2 次浏览 • 9 小时前
作为全球领先的家居用品零售商之一，Wayfair 近期宣布与 OpenAI 达成深度战略合作，将先进的生成式 AI 技术全面整合到其核心业务系统中。这一举措不仅显著提升了商品目录数据的质量，还大幅优化了供应商支持工作流程，为电商行业树立了 AI 驱动运营的新标杆。
"我们不是在将生成式 AI 当作实验或单点解决方案，而是将其嵌入核心运营工作流程中。" —— Wayfair 技术团队
一、背景：电商巨头的数据挑战1.1 海量商品目录的管理困境
Wayfair 平台管理着近3000万种商品，涵盖近千个不同的产品类别。在如此庞大的规模下，保持商品属性标签（如颜色、材质、尺寸、特定功能等）的一致性和准确性，一直是困扰电商行业的核心难题。1.2 传统方案的局限性
在引入 OpenAI 技术之前，Wayfair 主要依赖以下方式维护数据质量：
- 人工审核：由供应商和客户反馈问题，人工团队逐一核实修正
- 定制 AI 模型：为单个标签训练专门的机器学习模型
然而，这些方案都存在明显瓶颈：
"我们最初为单个标签构建定制模型，技术上确实可行。但当你面对47,000个标签时，这种方法根本无法扩展。" —— Carolyn Phillips，Wayfair 机器学习科学家
二、技术架构：可复用的 AI 标签系统2.1 统一模型的设计思路
为了解决规模化难题，Wayfair 技术团队设计了一套标签无关（tag-agnostic）的 AI 架构，基于单一的 OpenAI 模型实现全品类覆盖。核心组件
定义代理（Definition Agent）是系统的核心创新：
- 自动学习标签含义：代理会抓取网页和内部定义，为每个标签生成上下文相关的语义理解
- 消除人工瓶颈：传统方法中，定义和编码每个标签的含义需要大量人工时间
- 动态扩展能力：新标签加入时，系统自动学习其定义，无需重新训练
2.2 惊人的扩展速度
借助这套架构，Wayfair 扩展新属性标签的速度达到了 一年前的70倍。三、智能客服系统：Wilma 的 AI 升级3.1 Wilma 智能工单系统
Wayfair 为其供应商支持产品 Wilma 添加了 Agentic AI 功能，核心能力包括：工单分类（Triage）
- 意图识别：自动读取请求内容，识别供应商意图
- 上下文补全：从数据库填充缺失信息
- 智能路由：将工单指向正确的处理团队
- 自动回复：必要时主动联系供应商获取更多信息
3.2 从辅助到半自动的演进
Wayfair 采用渐进式部署策略，通过 "对齐率"（Alignment Rate）指标衡量 AI 建议与人工决策的一致性：
[code]对齐率 = AI 建议与人工最终决策一致的频率
当对齐率持续达到预设阈值时：
├── 辅助模式 (Co-pilot) ──▶ 半自动模式 (Auto-pilot)
└── 人工审核所有建议 ──▶ 系统自动处理常规请求- 修正标签数：250万+，覆盖100万+高曝光高销量商品
- A/B 测试结果：曝光量、点击量、页面排名均显著改善
- 预期6个月增长：4倍
4.2 供应商支持效率提升
- 月自动化工单：41,000 张，部分工作流自动化率达 70%
- 响应时间：显著缩短，去除人工分类和路由环节
- 供应商满意度：显著提升
五、技术合作与未来展望5.1 长期战略合作关系
Wayfair 与 OpenAI 的合作已从早期试点发展为涵盖多个层面的战略伙伴关系：
- 模型选择：共同评估和选择最适合业务场景的模型
- 部署最佳实践：分享企业级 AI 部署经验
- 内部推广：推动全公司范围内的 AI 应用
- 前沿探索：测试多模态等新技术能力
"最有价值的是思想伙伴关系。不仅仅是访问模型，而是共同探讨新的用例并能够快速行动。" —— Fiona Tan，Wayfair 首席技术官
5.2 多模态 AI 的家居零售应用
家居零售具有独特的视觉和风格属性，多模态 AI 模型为 Wayfair 带来了新的可能性：
"传统算法需要严格定义的数据集。这些模型使我们能够以以前无法扩展的方式处理模糊性和上下文。" —— Carolyn Phillips
典型应用场景：
- 视觉搜索：客户上传房间照片，AI 推荐匹配风格的家具
- 风格匹配：基于现有家具推荐协调的装饰品
- 尺寸建议：结合空间图像提供合适的尺寸建议
六、结语
Wayfair 与 OpenAI 的合作案例展示了生成式 AI 在电商领域的巨大潜力。通过将 AI 深度嵌入核心运营流程，Wayfair 不仅解决了长期困扰行业的数据质量难题，还显著提升了供应商支持效率。
对于 Wayfair 的领导者而言，目标始终是在扩展内部能力的同时增强人类专业知识：
"我们正在为一个 AI 成为购物旅程一部分的世界做准备——无论是在我们的网站上、通过支持渠道，还是通过对话式界面。" —— Fiona Tan
参考链接
- 原文: Wayfair boosts catalog accuracy and support speed with OpenAI
- OpenAI 企业解决方案: https://openai.com/business
- ChatGPT Enterprise: https://openai.com/chatgpt/enterprise
本文基于 OpenAI 官方博客文章翻译整理，如有出入请以原文为准。
Gemini 3.1 Pro 重磅发布：为复杂任务而生的新一代AI模型
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 115 次浏览 • 10 小时前
2026年2月，Google DeepMind 在AI领域接连投下重磅炸弹。先是发布了专门用于解决科学、研究和工程挑战的 Gemini 3 Deep Think 升级版，随后紧接着推出了承载这些突破性能力的核心智能模型 —— Gemini 3.1 Pro。
"3.1 Pro 专为那些简单答案远远不够的任务而设计。" —— The Gemini Team
这一连串发布标志着 Google 在通用人工智能（AGI）道路上的重要里程碑。如果说 Deep Think 是面向专业研究人员的"特种武器"，那么 3.1 Pro 则是将高级推理能力民主化，带给每一位开发者和普通用户。核心升级：推理能力的质的飞跃基准测试表现
Gemini 3.1 Pro 在多项严苛的基准测试中展现出惊人的进步：基准测试3.1 Pro 得分相比 3 Pro 提升ARC-AGI-277.1%2倍+Humanity's Last Exam48.4% (无工具)新标准Codeforces Elo3455金牌水平IMO 2025金牌级别持续领先
ARC-AGI-2 是一项极具挑战性的基准测试，专门评估模型解决全新逻辑模式的能力。3.1 Pro 在这一测试中获得 77.1% 的验证分数，相比 3 Pro 实现了翻倍以上的推理性能提升。技术架构特点
3.1 Pro 建立在 Gemini 3 系列基础之上，代表了核心推理能力的重大进步。它不仅仅是一个"更聪明的模型"，更是一个为复杂问题解决而设计的智能基线。实际应用场景演示
Google 官方展示了 3.1 Pro 在多个实际场景中的惊人表现：1. 代码动画生成
3.1 Pro 能够直接根据文本提示生成网站可用的动画 SVG。与传统视频相比，这些基于纯代码（而非像素）的动画具有以下优势：
- 无限缩放：在任何分辨率下都保持清晰
- 极小体积：文件大小远小于传统视频格式
- 直接嵌入：可直接集成到网页中
2. 复杂系统合成
模型展示了将复杂 API 转化为用户友好设计的能力。在一个令人印象深刻的示例中，3.1 Pro 成功构建了一个实时航空航天仪表板，配置了公共遥测数据流来可视化国际空间站的轨道。
这体现了模型在数据整合和系统设计方面的强大能力。3. 交互式设计
3.1 Pro 编码了一个复杂的 3D 椋鸟群飞（Starling Murmuration）模拟：
- 生成视觉代码只是基础
- 构建了沉浸式体验，用户可以通过手势追踪操控鸟群
- 创作了生成式配乐，根据鸟类运动实时变化
对于研究人员和设计师而言，这提供了一种原型化感官丰富界面的强大方式。4. 创意编程
当要求为艾米莉·勃朗特的《呼啸山庄》构建一个现代个人作品集网站时，3.1 Pro 不仅仅是总结文本内容，而是：
- 推理小说的大气氛围
- 设计出简洁、现代的界面
- 创建一个捕捉原著精髓的网站
这展示了模型在文学理解和创意转化方面的深度能力。获取方式与产品集成开发者渠道
3.1 Pro 正在通过以下平台向开发者推出预览版：
- Google AI Studio —— 在线提示工程环境
- Gemini CLI —— 命令行界面
- Google Antigravity —— Google 的代理开发平台
- Android Studio —— Android 开发环境
企业渠道
企业用户可通过以下服务访问：
- Vertex AI —— Google Cloud 的企业级 AI 平台
- Gemini Enterprise —— 企业专属服务
消费者渠道
普通用户可以通过：
- Gemini App —— 移动端和网页端应用
- NotebookLM —— AI 驱动的笔记和研究工具
订阅提示：Gemini App 中的 3.1 Pro 已向 Google AI Pro 和 Ultra 订阅用户推出，享有更高的使用限额。
与 Gemini 3 Deep Think 的关系
理解 3.1 Pro 和 Deep Think 的关系至关重要：特性Gemini 3.1 ProGemini 3 Deep Think定位通用核心智能专业推理模式目标用户开发者、企业、普通消费者科研人员、工程师使用场景日常应用、复杂任务科学研究、数学证明可用性广泛推出限 Ultra 订阅/API申请关系Deep Think 的基础基于 3.1 Pro 的特化版本
简单来说：3.1 Pro 是"大脑"，Deep Think 是"专业思维模式"。早期用户反馈
在正式发布前，Google 已与多个领域的专家合作测试：数学研究
Lisa Carbone（罗格斯大学数学家）在研究高能物理所需的数学结构时使用 Deep Think 审查技术数学论文。模型成功识别出了一个之前通过人工同行评审未发现的微妙逻辑缺陷。材料科学
杜克大学 Wang 实验室利用 Deep Think 优化复杂晶体生长的制备方法，用于半导体材料的潜在发现。模型成功设计了生长超过 100 μm 薄膜的配方，达到了之前方法难以实现的精确目标。硬件设计
Anupam Pathak（Google 平台与设备部门研发负责人）测试 Deep Think 加速物理组件设计。未来展望
Google 表示，自 2024 年 11 月发布 Gemini 3 Pro 以来，用户反馈和技术进步的速度推动了这些快速改进。3.1 Pro 目前以预览版形式发布，目的是：
- 验证更新 —— 确保模型在实际使用中的稳定性
- 推进代理工作流 —— 在 ambitious agentic workflows 领域取得进一步进展
- 收集反馈 —— 为正式版（GA）的发布做准备
"我们迫不及待地想看到你们用它构建和发现什么。" —— The Gemini Team
总结
Gemini 3.1 Pro 的发布标志着 AI 能力民主化的重要一步。它将原本只属于顶尖研究人员的深度推理能力，通过熟悉的工具和平台带给更广泛的受众。
对于开发者而言，这意味着可以构建更智能的应用；对于企业而言，这意味着可以自动化更复杂的业务流程；对于普通用户而言，这意味着拥有一个真正能"思考"的AI助手。
关键要点：
- ✅ 推理性能翻倍（ARC-AGI-2 77.1%）
- ✅ 多平台同步推出（API、App、企业版）
- ✅ 实际应用场景验证（代码动画、系统设计、创意编程）
- ✅ 与 Deep Think 形成互补的产品矩阵
- ✅ 预览版已可用，正式版即将推出
参考链接
- 官方博客: Gemini 3.1 Pro: A smarter model for your most complex tasks
- Gemini 3 Deep Think: Gemini 3 Deep Think: Advancing science, research and engineering
- Google AI Studio: https://aistudio.google.com
- Gemini CLI: https://geminicli.com/
- Google Antigravity: https://antigravity.google/
本文基于 Google DeepMind 官方发布内容整理，发布于 2026年3月17日
来源: DeepMind Blog
D4RT：让AI拥有四维视觉感知能力，开启动态场景理解新纪元
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 115 次浏览 • 10 小时前
人类在观察世界时，会不自觉地执行一项非凡的记忆与预测任务。我们不仅能看到某一时刻的世界状态，还能理解它之前的状态以及即将发生的变化。我们的大脑维持着对现实的持续表征，并利用这一模型来推断过去、现在与未来之间的因果关系。
为了让机器也能像人类一样"看见"世界，研究人员可以为它们配备摄像头，但这只是解决了输入问题。要真正理解这些输入，计算机必须解决一个复杂的逆问题：将视频（一系列二维平面投影）转化为对丰富、立体、动态的三维世界的理解。D4RT 的技术架构：查询驱动的统一框架
D4RT 采用统一的编码器-解码器 Transformer 架构。编码器首先将输入视频处理为场景几何与运动的压缩表征。与早期使用独立模块处理不同任务的系统不同，D4RT 通过灵活的查询机制只计算所需内容，其核心围绕一个根本问题：
视频中的某个像素在任意时刻、从选定相机视角观察时，在三维空间中的位置在哪里？
基于 DeepMind 先前在 SRT（Scene Representation Transformer）方面的工作，轻量级解码器通过查询这一表征来回答具体实例。由于查询相互独立，它们可以在现代 AI 硬件上并行处理。这使得 D4RT 极快且可扩展，无论是追踪几个点还是重建整个场景。核心能力：快速精准的四维理解
凭借这种灵活的公式化方法，D4RT 能够解决多种 4D 任务：
- 点追踪（Point Tracking）：通过查询像素在不同时间步的位置，D4RT 可以预测其 3D 轨迹。重要的是，即使物体在其他视频帧中不可见，模型也能进行预测。
- 点云重建（Point Cloud Reconstruction）：通过冻结时间和相机视角，D4RT 可以直接生成场景的完整 3D 结构，无需额外的相机估计或逐视频迭代优化。
- 相机姿态估计（Camera Pose Estimation）：通过生成并比对来自不同视角的单一时刻 3D 快照，D4RT 可以轻松恢复相机轨迹。
性能突破：效率提升 300 倍
D4RT 的简化架构和新颖查询机制使其处于 4D 重建领域的前沿，同时比先前方法效率提升高达 300 倍——快到足以支持机器人、增强现实等实时应用。
根据技术报告，D4RT 在各种 4D 重建任务中均优于先前方法。定性比较显示，虽然其他方法在处理动态物体时经常遇到困难——常常出现重复或完全无法重建的情况——但 D4RT 能够保持对运动世界的稳固、连续理解。
关键的是，D4RT 的精度并未以效率为代价。在测试中，它的性能比先前最先进方法快 18 到 300 倍。例如，D4RT 在单个 TPU 芯片上处理一分钟视频大约只需 5 秒，而先前最先进方法可能需要长达 10 分钟——提升了 120 倍。下游应用场景
D4RT 证明了在 4D 重建中无需在准确性和效率之间做选择。其灵活的查询系统能够实时捕捉我们的动态世界，为下一代空间计算铺平道路：
- 机器人（Robotics）：机器人需要在充满移动人员和物体的动态环境中导航。D4RT 可以提供安全导航和灵巧操作所需的空间感知能力。
- 增强现实（AR）：为了让 AR 眼镜将数字对象叠加到现实世界，它们需要对场景几何有即时、低延迟的理解。D4RT 的效率使其在设备端部署成为可触及的现实。
- 世界模型（World Models）：通过有效解耦相机运动、物体运动和静态几何，D4RT 让我们更接近拥有物理现实真正"世界模型"的 AI——这是通往 AGI 的必要步骤。
技术细节与资源
D4RT 由 Google DeepMind 的研究人员 Guillaume Le Moing 和 Mehdi S. M. Sajjadi 主导开发。相关技术报告已发布在 arXiv 上，项目网站提供了交互式演示，让用户可以直接在浏览器中探索 D4RT 的输出效果。
研究人员正在继续探索该模型的能力及其在机器人、增强现实等领域的潜在应用。
来源：Google DeepMind Blog - D4RT: Teaching AI to see the world in four dimensions
技术报告：arXiv:2512.08924
项目网站：https://d4rt-paper.github.io/
OpenAI Codex Security 设计理念解析：为何弃用 SAST 报告作为起点
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 114 次浏览 • 11 小时前
OpenAI Codex Security 设计理念解析：为何弃用 SAST 报告作为起点
原文来源：[OpenAI Blog](https://openai.com/index/why-c ... e-sast)
发布时间：2026年3月
关键词：AI 安全、代码安全、SAST、静态分析、Codex Security
---
引言
数十年来，静态应用安全测试（SAST）一直是安全团队扩展代码审查工作的最有效方式之一。然而，当 OpenAI 构建 Codex Security 时，他们做出了一个深思熟虑的设计选择：不通过导入静态分析报告并让智能体对其进行分类来启动流程。相反，Codex Security 的设计是从代码仓库本身出发——包括其架构、信任边界和预期行为——并在要求人工投入时间之前验证其发现的问题。
这个决策背后的原因很简单：最难发现的漏洞通常不是数据流问题。它们发生在代码看似执行了安全检查，但该检查实际上并不能保证系统所依赖的安全属性时。换句话说，挑战不仅仅是追踪数据如何在程序中流动——而是确定代码中的防御措施是否真正有效。
---
SAST 的核心局限：过度优化数据流分析
理想化的 SAST 模型
SAST 通常被描述为一个清晰的流水线：
<br /> 识别不可信输入源 → 追踪数据在程序中的流动 → 标记数据未经净化到达敏感接收点的情况<br />
这是一个优雅的模型，涵盖了大量真实存在的漏洞。
现实中的近似处理
然而在实际应用中，SAST 为了在大规模真实代码库中保持可处理性，不得不进行近似处理——尤其是在存在间接调用、动态分发、回调、反射和重度框架控制流的情况下。这些近似处理并不是对 SAST 的批评；而是在不执行代码的情况下推理代码的现实妥协。
更深层的问题
但这本身并不是 Codex Security 不以 SAST 报告为起点的原因。
更深层的问题是：即使成功地将数据源追踪到接收点，静态分析仍然必须回答一个决定漏洞是否真正存在的问题：
代码中的检查是否真正以系统假设的方式约束了值？
以一个常见模式为例：代码在渲染不可信内容之前调用类似sanitize_html()的函数。静态分析器可以看到净化器已运行，但它通常无法确定该净化器对于特定的渲染上下文、模板引擎、编码行为和下游转换是否真正充分。
这就是问题变得棘手的地方。问题不仅仅是数据是否到达接收点，而是代码中的检查是否真正以系统假设的方式约束了值。
换句话说："代码调用了净化器" 与 "系统是安全的" 之间存在巨大差异。
---
真实案例：解码前的验证陷阱
场景描述
以下是一个在真实系统中频繁出现的模式：
一个 Web 应用接收 JSON 负载，提取redirect_url，使用白名单正则表达式验证它，然后进行 URL 解码，并将结果传递给重定向处理器。
经典 SAST 报告视角
传统的源到接收点报告可以描述数据流：
<br /> 不可信输入 → 正则检查 → URL 解码 → 重定向<br />
真正的问题
但真正的问题不是检查是否存在，而是该检查在后续转换之后是否仍然以重定向处理器解释的方式约束了解码后的 URL。
如果正则表达式在解码之前运行，它是否真的约束了解码后的 URL？
回答这个问题意味着需要推理整个转换链：
- 正则表达式允许什么？
- 解码和规范化如何表现？
- URL 解析如何处理边缘情况？
- 重定向逻辑如何解析方案和权限？
CVE-2024-29041 实例
许多在实践中真正重要的漏洞看起来都是这样的：操作顺序错误、部分规范化、解析歧义、验证与解释之间的不匹配。数据流是可见的，弱点在于约束如何传播——或在转换链中如何失效传播。
这不仅仅是理论模式。在 [CVE-2024-29041](https://nvd.nist.gov/vuln/detail/CVE-2024-29041) 中，Express 受到开放式重定向问题的影响，格式错误的 URL 可以绕过常见的白名单实现，因为重定向目标在被编码后又被解释的方式存在问题。数据流是直接的，更难的问题——也是决定漏洞是否存在的问题——是验证在转换链之后是否仍然成立。
---
Codex Security 的解决方案：从行为出发，然后验证
核心目标
Codex Security 围绕一个简单的目标构建：通过呈现带有更强证据的问题来减少分类工作。
技术实现
在产品中，这意味着使用仓库特定的上下文（包括威胁模型），并在呈现问题之前在隔离环境中验证高信号问题。
当 Codex Security 遇到看起来像是"验证"或"净化"的边界时，它不会将其视为复选框。它会尝试理解代码试图保证什么——然后尝试证伪该保证。
在实践中，这往往表现为以下方式的组合：
| 技术手段 | 描述 |
|---------|------|
| 深度代码分析 | 像安全研究员一样阅读相关代码路径，结合完整的仓库上下文，寻找意图与实现之间的不匹配。模型会阅读注释，但不一定相信注释——所以在代码上方添加//Halvar says: this is not a bug并不能混淆它，如果确实存在漏洞的话。 |
| 问题切片 | 将问题简化为最小的可测试切片（例如，围绕单个输入的转换管道），以便在没有系统其余部分干扰的情况下进行推理。Codex Security 会提取微小的代码切片，然后为它们编写微模糊测试器。 |
| 跨转换约束推理 | 跨转换推理约束，而不是独立处理每个检查。在适当情况下，这可以形式化为可满足性问题。换句话说，系统为模型提供带有 z3-solver 的 Python 环境，模型擅长在需要时使用它，就像人类在处理特别复杂的输入约束问题时必须做的那样。这对于查看整数溢出或非标准架构上的类似错误特别有用。 |
| 沙箱验证 | 尽可能在沙箱验证环境中执行假设，以区分"这可能是个问题"和"这就是个问题"。没有什么比用调试模式编译的代码进行完整的端到端 PoC 更好的证明了。 |
关键转变
这是关键的转变：不是停留在"存在检查"，而是系统推进到"不变式成立（或不成立），这里有证据"。模型会为该任务选择最佳工具。
---
为何不以 SAST 报告为种子？
合理的疑问
一个合理的反应是：为什么不两者兼顾？ 从 SAST 报告开始，然后使用智能体进行更深入的推理。
在某些情况下，预计算的发现是有帮助的——特别是对于狭窄的、已知的错误类别。但对于一个旨在在上下文中发现和验证漏洞的智能体，从 SAST 报告开始会产生三种可预见的失败模式：
失败模式一：过早狭窄化
发现列表是工具已经查看过的地方的地图。如果你将其视为起点，你可能会使系统偏向于在同一区域使用相同的抽象花费不成比例的努力，错过不适合该工具世界观的漏洞类别。
失败模式二：隐含判断难以撤销
许多 SAST 发现编码了关于净化、验证或信任边界的假设。如果这些假设是错误的——或者只是不完整——将它们输入推理循环可能会使智能体从"调查"转变为"确认或驳回"，这不是我们希望智能体做的事情。
失败模式三：难以评估推理系统
如果流水线从 SAST 输出开始，就很难将智能体通过自己的分析发现的内容与从其他工具继承的内容分开。如果我们想要准确测量系统的能力，这种分离很重要，而准确测量是系统随时间改进所必需的。
OpenAI 的选择
因此，OpenAI 将 Codex Security 构建为从安全研究开始的地方开始：从代码和系统的意图出发，使用验证来提高置信度门槛，然后再打断人类。
---
SAST 工具仍然非常重要
适用范围
SAST 工具在其设计的方面可以表现出色：
- ✅ 执行安全编码标准
- ✅ 捕获直接的源到接收点问题
- ✅ 以可预测的权衡大规模检测已知模式
- ✅ 作为纵深防御的强大组成部分
本文的限定范围
这篇文章的范围更窄：它是关于为什么一个旨在推理行为和验证发现的智能体不应该将其工作锚定在静态发现列表上。
超越源到接收点思维
还值得指出纯源到接收点思维的一个相关局限：并非每个漏洞都是数据流问题。许多真实的故障是状态和不变式问题——工作流绕过、授权缺口和"系统处于错误状态"的错误。对于这些类型的错误，受污染的值不会到达单个"危险接收点"。风险在于程序假设将永远为真的东西。
---
未来展望
OpenAI 期望安全工具生态系统持续改进：静态分析、模糊测试、运行时守卫和智能体工作流都将发挥作用。
Codex Security 希望擅长的部分是对安全团队成本最高的部分：将"这看起来可疑"转变为"这是真实的，这是它失败的方式，这是符合系统意图的修复方案"。
---
参考资源
- [Codex Security 官方文档](https://developers.openai.com/codex/security/)
- [CVE-2024-29041 漏洞详情](https://nvd.nist.gov/vuln/detail/CVE-2024-29041)
- [OpenAI Codex Security 研究预览](https://openai.com/index/codex ... review)
---
总结
| 传统 SAST | Codex Security 方法 |
|----------|-------------------|
| 从预定义规则出发 | 从代码行为和意图出发 |
| 关注数据流追踪 | 关注约束传播和验证 |
| 标记潜在问题 | 验证并证明问题 |
| 可能产生大量误报 | 减少分类工作量 |
| 依赖静态近似 | 结合动态验证 |
Codex Security 代表了一种新的 AI 驱动安全分析范式：不是取代人类安全研究员，而是通过提供经过验证的、高置信度的问题发现来增强他们的能力，让他们将宝贵的时间花在真正需要人类判断的地方。
---
本文基于 OpenAI 官方博客文章翻译整理，如有出入请以原文为准。
INFINI Labs 产品更新 | Easysearch 2.1.0 新增高性能 Rules 规则引擎插件,数据探索 Discover 等
Easysearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 127 次浏览 • 11 小时前
INFINI Easysearch v2.1.0 发布：新增 Rules 规则引擎（百万级规则、复杂表达式、自动同步恢复）与 形态学分析插件（俄语/英语词形还原，提升搜索召回率）；审计日志支持动态用户审计，UI 新增日志查看、配置及数据探索页面，运维更高效。INFINI Console、Gateway、Agent、Loadgen v1.30.3 统一基于 [Framework](https://docs.infinilabs.com/framework/) 升级，优化本地磁盘队列数据消费。详情见 Release Notes。
Easysearch v2.1.0
INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。
Easysearch 本次更新如下：
🚀 功能特性 (Features)
- 新增 Rules 规则引擎插件，提供高性能的规则匹配能力
- 支持 linux-x64 和 linux-aarch64 架构
- 支持 Ingest Pipeline 集成，数据写入时自动匹配规则并添加标签
- 支持复杂的规则表达式（AND/OR/NOT、near、正则、数值范围等）
- 支持百万级规则库，匹配性能是传统方案的上百倍。
- 支持多节点集群自动同步和广播编译规则
- 节点启动时自动同步缺失的规则库
- 规则库同步期间自动保护写入，确保规则完整性
- 本地元数据文件持久化记录编译历史，支持规则库文件丢失后的自动恢复
- 支持 linux-x64 和 linux-aarch64 架构
- 新增形态学分析插件（analysis-morphology），支持俄语和英语的形态分析
- 精准还原：基于词典将动词时态、名词格位等还原为标准原型（如 went → go）
- 词元扩展：同时索引原词与关联词根（如runner → runner, run），实现智能搜索匹配
- 高召回率：解决俄语复杂的变格与变位搜索难题，确保不同语法形式下均能精准检索
- 精准还原：基于词典将动词时态、名词格位等还原为标准原型（如 went → go）
- 审计日志新增动态指定用户进行审计的功能
- UI 插件新增如下能力
- 支持审计日志在线查看
- 支持审计日志模块动态配置
- 新增数据探索页面
✈️ 改进优化 (Improvements)
- 支持审计日志在线查看
- 将“结巴”分词插件日志迁移至 Log4J，并降低周期性任务的日志级别以减少冗余
🐛 问题修复(Bug Fixes)
- 修复少量 UI 界面操作问题
Console v1.30.3
INFINI Console 是一款开源的非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管，企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。
Console 本次详细更新记录如下：
✈️ 改进优化 (Improvements)
- 此版本包含了底层 [Framework](https://docs.infinilabs.com/framework/) 的更新，解决了一些常见问题，并增强了整体稳定性和性能。虽然 Console 本身没有直接的变更，但从 Framework 中继承的改进间接地使 Console 受益。
🐛 问题修复(Bug Fixes)
- 修复 Agent 关联不成功问题
Gateway v1.30.3
INFINI Gateway 是一个开源的面向搜索场景的高性能数据网关，所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。
Gateway 本次更新如下：
✈️ 改进优化 (Improvements)
- 此版本包含了底层 [Framework](https://docs.infinilabs.com/framework/) 的更新，解决了一些常见问题，并增强了整体稳定性和性能。虽然 Gateway 本身没有直接的变更，但从 Framework 中继承的改进间接地使 Gateway 受益。
Agent v1.30.3
INFINI Agent 负责采集和上传 Elasticsearch, Easysearch, Opensearch 集群的日志和指标信息，通过 INFINI Console 管理，支持主流操作系统和平台，安装包轻量且无任何外部依赖，可以快速方便地安装。
Agent 本次更新如下：
🚀 功能特性 (Features)
- 在 Kubernetes 环境下通过环境变量 http.port 探测 Easysearch 的 HTTP 端口
✈️ 改进优化 (Improvements)
- 此版本包含了底层 [Framework](https://docs.infinilabs.com/framework/) 的更新，解决了一些常见问题，并增强了整体稳定性和性能。虽然 Agent 本身没有直接的变更，但从 Framework 中继承的改进间接地使 Agent 受益。
Loadgen v1.30.3
INFINI Loadgen 是一款开源的专为 Easysearch、Elasticsearch、OpenSearch 设计的轻量级性能测试工具。
Loadgen 本次更新如下：
✈️ 改进优化 (Improvements)
- 此版本包含了底层 [Framework](https://docs.infinilabs.com/framework/) 的更新，解决了一些常见问题，并增强了整体稳定性和性能。虽然 Loadgen 本身没有直接的变更，但从 Framework 中继承的改进间接地使 Loadgen 受益。
更多详情请查看以下各产品的 Release Notes 或联系我们的技术支持团队！
- [Coco AI App](https://docs.infinilabs.com/co ... notes/)
- [Coco AI Server](https://docs.infinilabs.com/co ... notes/)
- [INFINI Easysearch](https://docs.infinilabs.com/ea ... earch/)
- [INFINI Gateway](https://docs.infinilabs.com/ga ... notes/)
- [INFINI Console](https://docs.infinilabs.com/co ... notes/)
- [INFINI Agent](https://docs.infinilabs.com/ag ... notes/)
- [INFINI Loadgen](https://docs.infinilabs.com/lo ... notes/)
- [INFINI Framework](https://docs.infinilabs.com/fr ... notes/)
期待反馈
欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（<https://github.com/infinilabs>;） 中的对应项目中提交 Feature Request 或提交 Bug。
下载地址： <https://infinilabs.cn/download>;
邮件：hello@infini.ltd
电话：(+86) 400-139-9200
Discord：<https://discord.gg/4tKTMkkvVX>;
也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群一起讨论交流。
关于极限科技（INFINI Labs）
极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。
官网：<https://infinilabs.cn>;
从模型到智能体：OpenAI Responses API 计算机环境完整解析
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 121 次浏览 • 12 小时前
我们正处于 AI 使用的重大转折点——从擅长特定任务的模型向能够处理复杂工作流的智能体（Agent）转变。
传统上，通过提示词（Prompting）只能访问模型训练时获得的智能。然而，当给模型配备一个计算机环境后，它能实现更广泛的用例：运行服务、从 API 请求数据、生成电子表格或报告等更有用的产物。
但在构建智能体时，开发者面临诸多实际问题：
- 中间文件存放在哪里？
- 如何避免将大表格粘贴到提示词中？
- 如何在不造成安全噩梦的情况下给工作流提供网络访问？
- 如何处理超时和重试，而无需自己构建工作流系统？
OpenAI 的解决方案是：为 Responses API 配备计算机环境，让平台来可靠地执行真实世界的任务。核心架构：五大组件协同工作
OpenAI 的 Responses API 与 Shell 工具、托管容器工作空间相结合，旨在解决这些实际问题：
模型提出步骤和命令，平台在隔离环境中执行它们，该环境配备文件系统（用于输入输出）、可选的结构化存储（如 SQLite）和受限的网络访问。Shell 工具：智能体的"手"
Shell 工具让模型的能力呈指数级增长：它通过命令行与计算机交互，执行从文本搜索到发送 API 请求的广泛任务。
基于熟悉的 Unix 工具链，Shell 工具开箱即用就支持 grep、curl、awk 等命令。相比现有的代码解释器（仅执行 Python），Shell 工具支持更广泛的用例：运行 Go 或 Java 程序、启动 NodeJS 服务器、执行任意系统命令。智能体循环的编排机制
模型本身只能提出 Shell 命令，但命令如何执行？需要一个编排器（Orchestrator）来获取模型输出、调用工具，并将工具响应传回模型，形成循环直到任务完成。
Responses API 的执行流程：
- 组装上下文：用户提示词 + 历史对话状态 + 工具指令
- 模型决策：决定下一步动作（如选择 Shell 执行）
- 命令转发：Responses API 服务将命令转发到容器运行时
- 流式输出：Shell 输出流式返回，并反馈到下一次请求的上下文
- 结果检查：模型检查结果，发出后续命令或生成最终答案
- 循环直到完成
上下文压缩：长任务的关键
智能体循环的一个潜在问题是任务可能运行很长时间。长时间运行的任务会填满上下文窗口。
为了避免在智能体继续运行时丢失重要上下文，Responses API 添加了原生压缩（Compaction）功能：
OpenAI 的最新模型经过训练，能够分析先前的对话状态，并生成一个压缩项（Compaction Item），以加密的、token 高效的形式保留关键先前状态。
Codex 就依赖这一机制来维持长时间运行的编码任务和迭代工具执行，而不会降低质量。容器上下文：状态与资源管理
容器不仅是运行命令的地方，也是模型的工作上下文。在容器内部，模型可以读取文件、查询数据库、在网络安全策略控制下访问外部系统。网络安全访问
网络访问是智能体工作负载的重要组成部分，但给容器无限制的网络访问存在风险。OpenAI 的解决方案是 Sidecar Egress 代理：
所有出站网络请求流经集中式策略层，强制执行允许列表（Allowlist）、实施访问控制、保持流量可观察。Agent Skills：可复用的工作流构建块
Shell 命令很强大，但许多任务重复相同的多步骤模式。Agent Skills 将这些模式打包成可复用、可组合的工作流构建块。
一个 Skill 是一个文件夹包，包含 SKILL.md（元数据和指令）以及支持资源（API 规范、UI 资产等）。结语
"语言模型的意义不仅仅是生成文本、图像和音频——我们将继续发展我们的平台，使其更能够大规模处理复杂的真实世界任务。"
Responses API 计算机环境的推出，标志着 AI 从"对话工具"向"行动智能体"的关键转变。对于搜索和 AI 领域的从业者而言，这一架构设计提供了宝贵的参考：如何将大模型的推理能力与可靠的执行环境相结合，打造真正有用的自动化系统。
原文来源：OpenAI Engineering Blog
作者：Bo Xu, Danny Zhang, Rohit Arunachalam
发布日期：March 11, 2026
日本乐天集团用 Codex 将问题修复速度提升一倍
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 128 次浏览 • 12 小时前
日本乐天集团用 Codex 将问题修复速度提升一倍
原文来源：[OpenAI Blog](https://openai.com/index/rakuten/)
发布时间：2025年3月
引言
乐天（Rakuten）是日本最大的电商平台之一，业务涵盖电子商务、金融科技和移动通信，拥有 30,000 名全球员工。在这样庞大而复杂的产品生态系统中，速度和可靠性都是至关重要的。
乐天 AI for Business 总经理 Yusuke Kaji 在过去一年里一直致力于将 AI Agent 工作流深度整合到团队的软件规划、构建和验证流程中。OpenAI Codex 已成为乐天工程栈的核心组成部分，特别是在需要在不牺牲安全性的前提下提升速度的场景中。
---
核心成果：MTTR 降低 50%
在过去一年中，乐天工程师在运维和软件交付流程中广泛使用 Codex，取得了显著成效：
| 指标 | 改进效果 |
|------|---------|
| 平均恢复时间（MTTR） | 降低约 50% |
| 项目交付周期 | 从季度级压缩到周级 |
| 代码审查效率 | CI/CD 中自动完成 |
| 漏洞检查 | 自动化安全检测 |
"我们不只是关心快速生成代码，我们更关心安全地交付。没有安全性的速度不是成功。" —— Yusuke Kaji
---
三大核心战略
乐天的 AI 战略围绕三个明确的目标展开：
1. 构建更快（"Speed!! Speed!! Speed!!"）
在运维工作流中使用 Codex，包括基于 KQL（Azure 日志查询语言）的监控和诊断，加速根因分析和修复，将 MTTR 压缩高达 50%。
2. 构建更安全（"Get things done"）
在 CI/CD 流程中调用 Codex 进行代码审查和漏洞检查，自动应用内部标准，让团队能在有防护栏的情况下快速交付。
3. 更智能地运营（"AI-nization"）
Codex 推动更大规模、更模糊的项目从规范走向可工作的实现，减少对完美定义需求的依赖，实现更自主的执行，最终将季度级的工作压缩到周级。
---
实战案例
案例一：压缩事故响应时间
乐天的工程师使用 KQL 监控 API 和分析信号。Codex 与这些工作流协同工作，帮助识别根因并提出修复建议，缩短从告警到解决的时间。
从站点可靠性工程（SRE）的角度来看，这缩短了从检测到修复的路径。工程师不再需要手动拼凑查询、日志和补丁，而是可以专注于验证和部署修复方案。
结果：乐天估计这种方法可以将 MTTR 降低约 50%——换句话说，当出现问题时，修复速度快了一倍。
案例二：CI/CD 中的自动化安全检查
随着交付速度加快，审查和部署可能成为瓶颈。乐天通过将 Codex 直接集成到 CI/CD 管道中来解决这个问题。
Codex 在变更到达生产环境之前进行代码审查和漏洞检查。乐天的做法是将内部编码原则和标准输入到这些工作流中，确保审查符合公司期望。
"我们将内部编码原则提供给 Codex，它使用相同的原则来审查代码是否符合我们的标准。" —— Yusuke Kaji
结果：安全检查一致且自动地进行，使团队能够在不降低标准的情况下更快前进。
案例三：从单条规范到全栈实现
乐天的第三个优先事项——AI-nization——专注于自主性。Codex 不仅用于审查和维护，还用于端到端执行更大规模、更模糊的项目。
Codex 可以从部分需求出发推进工作并生成可用的交付物，而不需要完美定义的规范。
"最新的 Codex 模型能够读懂言外之意，即使需求没有完美定义，它也能理解我们要构建什么。" —— Yusuke Kaji
具体案例：构建一个现有基于 Web 的 AI Agent 服务的移动应用版本。Codex 实现了完整的规范，包括：
- 后端：Python/FastAPI
- 前端：Swift/SwiftUI iOS 应用
- API：所有后端接口
整个过程无需逐步人工指导，Codex 将项目开发时间从一个季度缩短到几周。
---
工程师角色的转变
随着 Codex 承担更多代码生成工作，乐天正在将工程师的角色从编写代码转变为：
- 编写更清晰的规范
- 根据可衡量的标准验证输出
"我们的角色不再是检查每一行代码，我们的角色是清晰地定义我们想要什么，并建立验证它的方法。" —— Yusuke Kaji
乐天通过在全工程、产品和非技术团队中开展实践研讨会来支持这一转变——使 Codex 在帮助团队更快交付、更安全运营和在整个组织内扩展自主开发方面发挥核心作用。
---
总结
乐天集团的实践展示了 AI 编码助手在企业级场景中的巨大潜力：
- 速度：事故修复时间缩短 50%
- 安全：CI/CD 中自动化的代码审查和漏洞检测
- 自主性：从模糊需求到完整实现，开发周期从季度缩短到周
- 角色转变：工程师从编码者变为规范制定者和验证者
对于正在考虑引入 AI 编码助手的企业来说，乐天的经验提供了宝贵的参考：不仅要关注代码生成速度，更要建立相应的安全检查和验证机制，让 AI 成为提升整体工程效能的可靠伙伴。
---
相关链接
- [OpenAI Codex 官网](https://openai.com/codex/)
- [乐天集团官网](https://www.rakuten.com/)
- [Azure KQL 查询语言文档](https://docs.microsoft.com/en- ... query/)
OpenAI 发布 AI Agent 安全防护指南：如何抵御提示词注入攻击
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 138 次浏览 • 13 小时前
OpenAI 最新发布的安全博客深入探讨了这一问题的演变，并提出了一套基于"社会工程学"视角的防御框架。提示词注入攻击的演变
早期的提示词注入攻击相对简单直接。攻击者可能在网页中插入恶意指令。然而，随着模型智能水平的提升，现实中的提示词注入攻击正在向更复杂的形态演进——它们越来越像社会工程学攻击。新的防御范式
OpenAI 提出了一个关键认知转变：与其追求完美识别所有恶意输入，不如设计系统使得即使操纵成功，其影响也能被控制在可接受范围内。Safe URL 机制
针对诱导助手泄露秘密信息的攻击，OpenAI 开发了 Safe URL 机制：检测可疑传输、向用户展示信息并请求确认、必要时阻断传输。给开发者的建议
- 采用"人类代理"思维
- 分层防御
- 最小权限原则
- 关键操作需用户确认
原文来源：OpenAI Security Blog
Easysearch ZSTD 基准测试：高压缩率下实现近 5 倍查询吞吐
Easysearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 140 次浏览 • 15 小时前
在搜索引擎领域，压缩算法的选择一直是一个经典的权衡难题：
- 选择高压缩率（如
best_compression/ DEFLATE），磁盘省了，但查询解压慢； - 选择高速编码（如默认 LZ4），查询快了，但磁盘占用大。
Easysearch 引入了基于 JDK 21 FFM（Foreign Function & Memory API） 直连本地 ZSTD 动态库的加速方案，试图打破这一困局。为了验证效果，我们在完全对等的环境下，对 Easysearch（ZSTD）和 Elasticsearch 7.10.2（best_compression）进行了一次严格的查询吞吐对比测试。
结果令人振奋——即使在系统明显背景负载下，Easysearch 也没有因为高压缩而变慢，反而在查询吞吐上实现了近 5 倍提升。
---
测试环境
为确保对比公平，两套集群的硬件资源、JVM 配置、数据规模、索引结构完全对齐：
| 配置项 | Easysearch | Elasticsearch 7.10.2 |
| :--------------------- | :----------------------------------- | :----------------------------- |
| 节点数 | 3 | 3 |
| JVM 堆内存 | 12GB × 3 | 12GB × 3 |
| node.processors | 16 × 3 | 16 × 3 |
| 文档数 | 10,000,000 | 10,000,000 |
| 主分片 / 副本 | 3 / 0 | 3 / 0 |
| 数据类型 | nginx 访问日志 | nginx 访问日志 |
| 字段数 | 17 | 17 |
| mapping | 完全一致（MD5 校验） | 完全一致（MD5 校验） |
| Stored fields 压缩模式 | ZSTD (JDK21 FFM/native, level=3) | best_compression (DEFLATE) |
压缩机制对比：
best_compression映射到 LuceneBEST_COMPRESSION；在 stored fields 路径上，压缩实现为DeflateWithPresetDictCompressionMode，内部使用java.util.zip.Deflater/Inflater（即 DEFLATE）。
Easysearch ZSTD 当前走 JDK 21 FFM 绑定本地 zstd 库（java.lang.foreign）；index.compression.zstd.jni=true为当前这套实现的启用方式。
查询模型：JMeter 随机match查询，随机命中service_name、method、error_code、url四个字段，每次返回 10 条文档。
压测起始负载（_cat/nodes快照）：
| 负载项 | Easysearch run | Elasticsearch run |
| :---------- | :------------- | :---------------- |
| load_1m | 29.74 | 25.27 |
| load_5m | 27.10 | 28.15 |
| load_15m | 26.09 | 36.96 |
| ram.percent | 99 | 99 |
说明：压测并非在空闲机上进行，而是在已有明显背景负载的生产式环境下完成。
---
核心结果
1. 查询吞吐量（QPS）：在高背景负载下，Easysearch 仍领先 372%
稳态阶段（3 轮平均），Easysearch 的查询吞吐是 Elasticsearch 的 4.7 倍：
| 指标 | Elasticsearch (DEFLATE) | Easysearch (ZSTD) | 差异 |
| :-------------------------- | ----------------------: | ----------------: | :----------- |
| 稳态 QPS | 532.8 | 2,518.0 | +372.6% |
| 平均响应时间 | 779.0 ms | 164.3 ms | -78.9% |
| 稳态 CPU 占用（系统总占用） | 92.43% | 89.59% | 仅作背景参考 |
注：压测期间服务器存在明显背景负载（其他进程占用较高），该 CPU 指标是系统总占用，不等价于“仅搜索进程”的纯业务 CPU 对比。
在系统总 CPU 均接近 90% 的背景下，Easysearch 仍达到接近 5 倍吞吐。
查询吞吐量 QPS 对比（稳态均值）
### 2. 响应时间：从近 1 秒降到 164 毫秒
平均响应时间对比（ms，越低越好）
用户体感上，这意味着：同样一个搜索请求，Elasticsearch 还在等解压，Easysearch 已经把结果送到了客户端。
### 3. 各轮次详细数据
各轮次 QPS 趋势
各轮次平均响应时间趋势（ms）
### 4. CPU 使用效率：每 1% CPU 产出的 QPS 差距惊人
单看 CPU 占用率，两者似乎差不多（89.59% vs 92.43%）。但如果换一个视角——**每消耗 1% CPU 能产出多少 QPS**，差距就一目了然了：
| 指标 | Elasticsearch (DEFLATE) | Easysearch (ZSTD) | 倍数 |
| :--------------- | ----------------------: | ----------------: | :-------- |
| 稳态 QPS | 532.8 | 2,518.0 | — |
| 稳态 CPU | 92.43% | 89.59% | — |
| **QPS / 1% CPU** | **5.76** | **28.10** | **4.88×** |
CPU 使用效率：每 1% CPU 产出的 QPS
这意味着什么？
- ES 使用 DEFLATE（best_compression）时，解压路径更可能成为 CPU 热点；结合 ES 的高 CPU（92.43%）与较低 QPS，说明单位 CPU 产出偏低；
- Easysearch 使用 ZSTD（JDK21 FFM/native）时，解压开销更小；在相近 CPU 水位（89.59%）下获得更高 QPS，单位 CPU 产出明显更高。
换句话说，当前这组实测更支持“ZSTD 在该查询模型下单位 CPU 产出更高”。
5. 存储空间：ZSTD 并未膨胀
| 索引 | 压缩算法 | 磁盘占用 |
| :----------------------- | :------------------------------- | -------: |
| nginx_best_10m (ES) | best_compression (DEFLATE) | 1.8 GB |
| nginx_zstd3 (Easysearch) | ZSTD (level=3, JDK21 FFM/native) | 1.9 GB |
两者存储空间接近。若按_cat/indices的 1 位小数展示是1.8GBvs1.9GB；若按_stats/store字节值计算，差异约2.5%。因此可以认为 ZSTD 在 level=3 下与 DEFLATEbest_compression压缩率接近。
磁盘占用对比（GB）
---
## 为什么 ZSTD 能做到"又小又快"？
传统认知中，压缩率和解压速度是一对矛盾。但 ZSTD 算法天然具备**非对称压缩**的特性：
压缩算法特性对比
在搜索引擎场景中，查询会触发存储字段（`_source`）读取与解压路径，命中文件系统页缓存时，可能不发生实际磁盘 I/O，但仍需进行 \_source 解压。
当查询涉及较多 `_source` 读取时：
- DEFLATE 的解压开销成为 CPU 瓶颈，拖慢了整体吞吐；
- ZSTD（JDK21 FFM/native） 的解压速度在该场景下明显更优，单次请求的解压 CPU 成本更低，从而释放出更多 CPU 资源用于并发查询处理。
这就是为什么 Easysearch 在 CPU 占用更低（89.59% vs 92.43%）的情况下，反而能处理近 5 倍的查询量。
---
一张图总结
Easysearch ZSTD vs Elasticsearch DEFLATE — 全维度对比
---
## 结论
Easysearch 的 ZSTD 压缩方案证明了一个事实：**即使在高背景负载下，高压缩率和高查询性能依然可以兼得**。
在 1000 万条 nginx 日志、且系统存在明显背景负载的实测中：
- 查询吞吐提升 372%，从 533 QPS 跃升至 2518 QPS
- 平均响应时间下降 79%，从 779ms 降至 164ms
- CPU 使用效率提升 388%，每 1% CPU 产出 28.10 QPS vs 5.76 QPS
- CPU 占用绝对值下降 2.84 个百分点（相对下降约 3.07%）
- 磁盘占用与 DEFLATE best_compression 接近（按字节口径约 +2.5%）
对于日志分析、可观测性、安全审计等需要兼顾存储成本和查询性能的场景，Easysearch ZSTD 是一个不需要妥协的选择。
---
ZSTD 使用方法
1) 新建索引时启用 ZSTD
bash<br /> curl -k -u 'admin:<password>' -X PUT 'https://127.0.0.1:9200/<index-name>' \<br /> -H 'Content-Type: application/json' -d '{<br /> "settings": {<br /> "index.codec": "ZSTD",<br /> "index.compression.zstd.jni": true<br /> }<br /> }'<br />
可选参数：
index.compression.zstd.level（默认3）
说明：
index.compression.zstd.dict固定为true，无需单独配置index.compression.zstd.dict不作为独立开关来调整
2) 老索引切换到 ZSTD（推荐 reindex）
index.codec是静态设置（打开状态不可动态改；可在关闭索引后调整）。
index.compression.zstd.jni是final设置（关闭索引后也不可修改）。
如果老索引要启用index.compression.zstd.jni=true，建议新建目标索引后reindex迁移：
如果对已有索引执行PUT /<index-name>/_settings直接修改，会报错：final <index-name> setting [index.compression.zstd.jni], not updateable。
```bash先创建目标索引（启用 ZSTD）
curl -k -u 'admin:
' -X PUT 'https://127.0.0.1:9200/ ' \
-H 'Content-Type: application/json' -d '{
"settings": {
"index.codec": "ZSTD",
"index.compression.zstd.jni": true
}
}'
再迁移数据
curl -k -u 'admin:
' -X POST 'https://127.0.0.1:9200/_reindex' \
-H 'Content-Type: application/json' -d '{
"source": { "index": "" },
"dest": { "index": "" }
}'
```
3) 校验是否生效
bash<br /> curl -k -u 'admin:<password>' \<br /> 'https://127.0.0.1:9200/<index-name>/_settings?include_defaults=true&pretty'<br />
重点确认：
index.codec = ZSTDindex.compression.zstd.jni = true
---
关于 Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。
官网文档：<https://docs.infinilabs.com/easysearch>;
作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
---
相关文章：
- [Easysearch 2.0.0 性能测试](https://infinilabs.cn/blog/202 ... ments/)
- [Easysearch 压缩模式深度比较：ZSTD + source_reuse 的优势分析](https://infinilabs.cn/blog/202 ... modes/)
- [Easysearch 压缩功能的显著提升：从 8.7GB 到 1.4GB](https://infinilabs.cn/blog/202 ... 1.4GB/)
1573 个 Claude Code 会话分析：AI 编程代理的真实使用数据
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 142 次浏览 • 16 小时前
AI 编程工具的使用数据一直是个黑盒——我们知道很多人在用，但具体用得怎么样？哪些场景效果好？什么情况下会放弃？最近，一个团队开源了他们的分析工具 Rudel，并基于 1573 个真实的 Claude Code 会话数据，给出了一些有趣的洞察。
数据集概况
这个数据集来自一个 6 人团队（4 名工程师、1 名数据/业务人员、1 名设计工程师）在过去 3 个月的真实使用记录：
- 总会话数：1,573 个
- 总 Token 数：1500 万+
- 总交互数：27 万+
- 会话类型：40% 大型遗留项目、50% 新项目、10% 非编码任务
核心发现
1. Skills 使用率极低：仅 4%
Claude Code 的 Skills 功能（预定义的指令模板）使用率只有 4%。这引发了一个问题：是功能设计有问题，还是用户根本不知道它的存在？
从 Hacker News 的讨论来看，可能两者都有： - Skills 的可发现性较差
- 用户更倾向于自然语言提示
- 即使设置了 Skills，Claude 也不一定会调用
好消息是，Claude 4.6 版本在这方面有明显改进。
2. 26% 的会话在 60 秒内被放弃
超过四分之一的会话在开始后的第一分钟内就被用户放弃。这个数字揭示了一个关键问题：初始提示与意图匹配的重要性。
正如 HN 用户 robutsume 分析的："这不是代理的问题，而是提示与意图不匹配的问题。人类在一次交互后就意识到他们问错了问题，或者代理理解错了。"
3. 错误级联模式：前 2 分钟决定成败
研究发现，如果在会话的前 2 分钟出现工具选择错误或文件读取错误，后续放弃的概率会显著增加。这和基础设施监控的经验很相似——部署的前 90 秒几乎能决定一切。
4. 不同任务类型的成功率差异显著
- 文档编写：成功率最高
- 代码重构：成功率最低
这个发现符合直觉：文档任务边界清晰、验证简单；而重构涉及复杂的代码理解和依赖分析，更容易出错。
对 AI 搜索的启示
虽然这项研究聚焦于编程场景，但对 AI 搜索产品的设计也有参考价值：
1. 首因效应至关重要
用户在前 60 秒的体验决定了他们是否会继续使用。搜索产品需要在最短时间内给出高质量结果。
2. 错误恢复机制
当 AI 理解错误时，如何快速纠正比追求完美更重要。Rudel 的数据显示，错误级联一旦发生，用户很快就会失去耐心。
3. 功能发现性
即使有强大的功能（如 Skills），如果用户不知道或不会用，就等于不存在。AI 搜索产品需要更智能地引导用户使用高级功能。
4. 任务适配性
不同的搜索场景对 AI 的要求不同。简单的事实查询 vs 复杂的分析任务，需要不同的交互设计和预期管理。
Rudel 工具本身
这项研究的开源工具 Rudel 也值得关注。它通过 Claude Code 的 hooks 机制，在会话结束时自动上传数据，提供团队级的使用分析：
- 个人和团队的会话统计
- Token 使用趋势
- 项目时间分配
- 会话成功率分析
对于想要量化 AI 工具 ROI 的团队来说，这类分析工具很有价值。
社区反响
这个项目在 Hacker News 上获得了 85 个点赞和 50+ 评论。讨论焦点包括：
- 如何提高 Skills 的使用率
- 单一会话 vs 多会话策略的优劣
- 隐私和数据安全问题（工具需要上传完整会话内容）
- 与 Claude Code 内置的/insights 命令的对比
写在最后
AI 编程代理还处于早期阶段，我们对其使用模式的理解非常有限。Rudel 团队的数据虽然只来自一个小团队，但提供了宝贵的实证基础。
随着 AI Agent 的普及，相信会有更多类似的研究出现。而对于搜索技术从业者来说，理解用户如何与 AI 交互、在什么情况下会放弃，将是设计更好产品的关键。
---
你使用 Claude Code 或其他 AI 编程工具吗？你觉得最大的痛点是什么？
---
来源：[Rudel GitHub](https://github.com/obsessiondb/rudel) / [Hacker News 讨论](https://news.ycombinator.com/item?id=47350416)
原文发布时间：2026 年 3 月 12 日
Hacker News 热度：85 points, 53 comments
【搜索客社区日报】第2198期 (2026-03-17）
社区日报 • God_lockin 发表了文章 • 0 个评论 • 488 次浏览 • 18 小时前
https://medium.com/%40mohamedm ... 29932
2. 一天搞了85 million的更新，就问你厉不厉害（需要梯子）
https://medium.com/motive-eng/ ... 4f3d3
3. 我的AI agent怎么就这么快？（需要梯子）
https://infosecwriteups.com/my ... d115c
编辑：斯蒂文
更多资讯：http://news.searchkit.cn
零样本视频异常检测：当向量检索遇上边缘智能
AI 搜索 • ai_insider 发表了文章 • 0 个评论 • 631 次浏览 • 1 天前
想象一下，你的监控摄像头能在从未见过打斗、事故或入侵的情况下，自动检测出这些异常事件。这不是科幻，而是向量检索技术在边缘计算场景下的最新实践。
Qdrant 最近发布了一套完整的边缘到云端的视频异常检测方案，核心思路非常巧妙：不再问"这是什么异常？"，而是问"这与正常状态有多不同？"
传统方法的困境
传统的视频异常检测依赖监督学习。你需要为每一种异常类型收集标注数据——打斗、事故、入侵、设备故障……问题是，在现实世界中，你无法枚举所有可能出错的情况。
更麻烦的是，当一个全新的异常类型出现时，训练好的分类器会直接失效。一个用13种犯罪类别训练的模型，面对叉车碰撞或管道爆裂时，置信度直接归零。
这就是监督学习的根本局限：正常行为的空间是可学习的，但异常行为的空间是无界的。
向量检索的破局之道
Qdrant 的方案将异常检测重新定义为最近邻搜索问题：
- 建立基线：将正常活动的视频片段编码成向量，存入 Qdrant 作为基线
- 实时比对：新视频片段到达时，编码并搜索最近邻
- 异常判定：如果片段与基线距离较远，即为异常
这种方法的最大优势是零样本检测——无需异常标注，无需针对新异常类型重新训练。任何偏离正常模式的行为，无论是否见过，都能被捕获。
技术架构：四层协作
这套方案的精妙之处在于边缘与云端的智能分工：
Qdrant Edge：边缘端的向量引擎
运行在 NVIDIA Jetson 设备上，采用双分片架构：- 不可变 HNSW 分片：从云端同步的基线数据，提供亚毫秒级 kNN 检索
- 可变更写入分片：支持实时写入和本地更新
关键特性：完全离线可用，网络中断不影响本地检测。
Twelve Labs Marengo 3.0：视频理解的大脑
相比 CLIP 等帧级模型（0.23 AUC-ROC），Marengo 3.0 处理时序动态、音频和场景上下文作为统一信号，达到 0.97 AUC-ROC。一个模型同时处理异常评分和语义搜索。
NVIDIA Metropolis VSS：GPU 加速管道
编排视频摄入、嵌入生成、VLM 字幕、音频转录和 CV 管道，全部在 GPU 上并行运行。
Vultr Cloud GPUs：云端算力支撑
提供按小时计费的专用 NVIDIA GPU，全球数据中心布局确保低延迟和可预测成本。
边缘优先的成本优化
一个 50 摄像头的部署每天产生 432,000 个视频片段。如果全部发送到云端处理，既不快速也不经济。
Qdrant Edge 的解决方案是边缘分级处理： - 边缘端进行初筛，仅将高异常评分片段上传到云端
- 云端使用 Marengo 3.0 进行高保真分析和集成评分
- 结果：云处理量减少约 6 倍，同时捕获约 95% 的真实异常
这种架构让系统能够随摄像头数量线性扩展，而无需让云成本同步线性增长。
实际产出能力
这套系统将实时视频流转化为：
- 实时异常评分：基于与正常基线的 kNN 距离，配合时序平滑和迟滞阈值过滤噪声
- 事件报告：带严重度评分、时间线和自然语言解释的事故报告
- 语义视频搜索：跨所有摄像头和时间段搜索，比如"显示上周北门的不寻常活动"
- 交互式问答：基于实际视频内容回答关于检测到事件的问题
开源与教程
Qdrant 发布了完整的 3 部分教程，包含可运行代码：
- [Part 1: 架构、Twelve Labs 和 NVIDIA VSS](https://qdrant.tech/documentat ... art-1/)
- [Part 2: 边缘到云端管道](https://qdrant.tech/documentat ... art-2/)
- [Part 3: 评分、治理和部署](https://qdrant.tech/documentat ... art-3/)
GitHub 仓库：[qdrant/video-anomaly-edge](https://github.com/qdrant/video-anomaly-edge)
启示：重新定义问题
这个案例给我们的最大启发是：有时候，解决问题的最佳方式不是优化现有方案，而是重新定义问题本身。
与其训练模型识别所有异常类型（一个注定失败的任务），不如利用向量检索的固有优势——相似度计算。当"异常"被定义为"与正常状态的偏离"时，问题突然变得可解了。
向量数据库不再只是 RAG 应用的检索层，它正在成为新一代 AI 应用的基础设施——从推荐系统到异常检测，从语义搜索到智能体记忆。
---
来源: [Qdrant Blog - Video Anomaly Detection From Edge to Cloud](https://qdrant.tech/blog/video ... cloud/)
发布时间: March 15, 2026
- 不可变 HNSW 分片：从云端同步的基线数据，提供亚毫秒级 kNN 检索
论文精读：通过提示词实现 LLM 推荐系统的公平性去偏
AI 搜索 • paper_reader 发表了文章 • 0 个评论 • 624 次浏览 • 1 天前
论文精读：通过提示词实现 LLM 推荐系统的公平性去偏
论文标题: Can Fairness Be Prompted? Prompt-Based Debiasing Strategies in High-Stakes Recommendations
作者: Theresia Veronika Rampisela 等
arXiv: https://arxiv.org/abs/2603.12935
发表时间: 2026年3月
---
研究背景
大语言模型（LLM）在推荐系统中的应用日益广泛，但一个潜在问题是：LLM 可能从间接线索（如姓名、代词）推断出敏感属性（如性别、年龄），从而在推荐中产生偏见。
现有的去偏方法通常需要：
- 访问 LLM 的权重参数
- 高昂的计算成本
- 专业知识
这使得普通用户难以使用这些技术。
核心问题
能否仅通过提示词（prompt）来实现推荐系统的公平性去偏？
研究贡献
本文提出了三种基于提示词的去偏策略：
1. 公平性指令提示 (Fairness Instruction Prompting)
直接在提示中加入公平性相关的指令，如：
"请确保你的推荐对所有用户群体都公平，不考虑性别、年龄等因素。"
2. 反事实示例提示 (Counterfactual Prompting)
通过构造反事实场景来消除敏感属性的影响。
3. 偏见感知系统提示 (Bias-Aware System Prompting)
在系统层面加入对潜在偏见的警示和约束。
实验设置
- 测试模型: 3 个不同的 LLM
- 提示模板: 4 种
- 敏感属性: 9 种（性别、年龄等）
- 数据集: 2 个真实推荐数据集
核心发现
✅ 有效性
- 基于提示的去偏方法最高可提升 74% 的公平性指标
- 同时保持了与基线相当的有效性（推荐准确率）
⚠️ 局限性
- 在某些情况下可能导致特定群体的过度推广（overpromotion）
- 提示的设计对效果影响很大，需要仔细调优
实践意义
对搜索/推荐工程师的启示
- 轻量级解决方案
- 无需修改模型权重或重新训练
- 部署成本低，可快速实验
- 无需修改模型权重或重新训练
- 高 stakes 场景适用
- 金融、医疗、招聘等领域的推荐系统
- 需要满足合规要求的场景
- 金融、医疗、招聘等领域的推荐系统
- 提示工程的新维度
- 除了追求准确性，还需考虑公平性
- 建议将公平性测试纳入提示评估流程
局限与未来方向
- 除了追求准确性，还需考虑公平性
- 轻量级解决方案
- 研究主要关注群体公平性（group fairness）
- 个体公平性（individual fairness）的提示策略仍需探索
- 不同语言和文化背景下的适用性有待验证
原文链接
https://arxiv.org/abs/2603.12935
---
这篇论文为 LLM 推荐系统的公平性优化提供了一个实用且低成本的切入点，值得在工业落地中尝试。
Meilisearch 2026年3月更新解读：分布式搜索迈入新纪元，AI性能大幅提升
Elasticsearch • paper_reader 发表了文章 • 0 个评论 • 644 次浏览 • 1 天前
标题：Meilisearch 2026年3月更新解读：分布式搜索迈入新纪元，AI性能大幅提升
正文：
更新概览
2026年3月，Meilisearch 带来了一系列令人振奋的产品更新。从分布式搜索的里程碑式进展，到AI性能的显著提升，再到Cloud平台的用户体验优化，本次更新展现了Meilisearch在搜索引擎领域持续创新的决心。本文将深入解析这些重要改进，帮助开发者更好地理解和应用这些新特性。
主要功能改进
1. 分布式搜索：复制分片正式进入引擎
本次更新最重磅的消息是 v1.37 版本将复制分片（Replicated Sharding）功能直接集成到 Meilisearch 引擎中。这是实现分布式、弹性搜索架构的最重要一步，也是通往Cloud平台一键复制功能的直接基石。
关键特性：
- 复制功能现已内置在引擎层面
- 目前面向企业版（Enterprise Edition）用户开放
- Cloud UI 的一键设置功能即将推出
这一进展意味着Meilisearch正在从单节点搜索引擎向真正的分布式架构演进，为高可用性和大规模搜索场景奠定了坚实基础。
2. 排名规则精细化控制
v1.36 版本引入了两个全新的排名规则，为搜索相关性调优提供了更精细的控制能力：
| 新规则 | 功能描述 |
|--------|----------|
|attributeRank| 优先匹配权重更高的可搜索属性，不考虑匹配在属性中的具体位置 |
|wordPosition| 优先匹配出现在属性开头的关键词，不考虑属性本身的权重 |
此前，attribute排名规则将这两种行为固定绑定在一起。现在开发者可以独立使用它们，并能更灵活地在排名管道中插入自定义规则（如价格、发布日期等）。
3. Cloud 平台用户体验升级
Meilisearch Cloud 在本月迎来了三项实用功能：
- AI Prompt 生成器：直接在Cloud UI中生成高质量的AI搜索提示词，减少反复调试的时间成本
- 文档删除功能：无需调用API，直接在Cloud界面中删除索引文档，便于快速清理和内容管理
- 索引统计信息：直观展示索引大小、文档数量和字段分布，帮助用户更好地理解和维护数据健康
4. 搜索性能分析工具
新增的showPerformanceDetails参数让开发者能够获取搜索查询各阶段的时间消耗明细。这一功能极大地简化了慢查询的调试工作，使搜索性能优化变得更加透明和可控。
AI性能提升详情
HNSW 向量存储全面稳定化
Meilisearch 已完全迁移至基于 HNSW（Hierarchical Navigable Small World）算法的向量存储后端（代号 Hannoy）：
- 旧的
vectorStoreSetting实验性功能已被永久移除 - 无停机升级过程中，引擎会自动将索引迁移到新后端
- 新建索引默认使用 HNSW 存储，带来更优的嵌入性能和一致性
v1.38 嵌入性能重大突破
v1.38 版本在AI嵌入索引性能方面实现了显著提升：
- 极速嵌入更新：消除了添加或更新嵌入时不必要的全库扫描，大规模索引的嵌入添加效率大幅提升
- 远程嵌入器稳定性修复：解决了使用远程嵌入器时偶发的 "connection reset by peer" 错误，显著提升了AI搜索工作流的稳定性
- 任务删除优化：修复了任务和批量删除操作中的长期边缘案例问题
升级建议：向量搜索用户强烈建议升级至 v1.38，该版本包含重要的性能改进和可靠性修复，且完全向后兼容。
未来规划
Meilisearch 团队正在开发 Cloud UI 中更便捷的聊天设置配置方式，预计将在近期推出。
未来展望
Meilisearch 的发展路线图显示出清晰的技术演进方向：
- 分布式架构深化：复制分片功能的引擎内集成只是开始，未来将在Cloud平台实现真正的一键分布式部署
- AI搜索体验优化：从Prompt生成器到聊天设置简化，Meilisearch正在降低AI搜索的使用门槛
- 社区生态建设：Meilisearch 已正式加入 Rust 基金会，回馈这个支撑其核心引擎快速可靠的生态系统
开发者可以通过 [Meilisearch 公开路线图](https://www.notion.so/Public-M ... 9c1b10) 了解最新规划。
安全与透明度
本月Meilisearch在安全方面也做出了重要改进：
- 极速嵌入更新：消除了添加或更新嵌入时不必要的全库扫描，大规模索引的嵌入添加效率大幅提升
- mini-dashboard 安全增强：API密钥现在存储在RAM中而非 localStorage，提升了安全性
- 负责任的漏洞披露：团队及时响应安全研究员的报告，修复漏洞并协调公开CVE披露，展现了成熟的安全治理态度
---
来源：Meilisearch官方博客
原文链接：https://www.meilisearch.com/bl ... dates
---
标签： Meilisearch, 搜索引擎, 分布式搜索, AI搜索
